I agree, my suggestion would be creating a class variable, e.g. ARITHMETIC_TYPES.

In another opportunity we could also double check if there are no redundancies in these types and if there is no other way to support arithmetic with np types besides enumerating all of them.

Is it really better to make it a class attribute? We may need this being used out of the Function class eventually, therefore not attaching this constant to a class might be a better idea imo. I would simply define it at the top of the file as a python constant variable in UPPERCASE

Is it really better to make it a class attribute? We may need this being used out of the Function class eventually, therefore not attaching this constant to a class might be a better idea imo. I would simply define it at the top of the file as a python constant variable in UPPERCASE

Both solutions work of course.

My argument for it being a class variable (a variable pertaining to the class, such as Function.ARITHMETIC_TYPES) is that I believe that this variable only makes sense in a Function class related context.

In the end, the choice is mostly stylistic and I agree with answer given here . To sum up, I am perfectly happy with both ways, although I have a small semantic preference toward a class variable.

@phmbressan I recommend you reading this page: https://numpy.org/doc/stable/reference/generated/numpy.isscalar.html

No, using isscalar doesn't save our lives because a string is also a scalar apparently (???).
But they do a good recommendation: """If you need a stricter way to identify a numerical scalar, use isinstance(x, numbers.Number), as that returns False for most non-numerical elements such as strings."""